@JohannesGarm can you look at this since you've requested something similar?

This is close to the solution we discussed and a definite improvement to the current system. I see why you have to have the service itself set the creator variable but a mandatory call which is the same across all services is still counter-intuitive to me. I think it would be cleaner to have the formating for the string done by the set_creator function - I cant think of a situation where you can set it to any other string format and it would not just break.

Does this work when editing service config from the service code? If you create a leaf under root.services.properties, for instance?

Yesterday when I fixed the PR the first thing I realized was it would probably be better to have the set_creator method do the string formatting to make it cleaner. However, when I wrote it, I didn't fully understand what kinds of other attributes a person might want to apply when making this call. I figured this was a way to not box anyone out, they can feed any data in they want in case I overlooked something. I originally didn't expect to commit it, I thought I could find a way to augment the class at runtime later, but turns out that is harder than I thought.

I didn't check if it works for editing the service config, I've been using it for editing remote system configs. However, since it is a global variable in the Element class, as long as the tag is valid, it will work anywhere you are editing XML.

I will look at the docs again with regards to attributes and then look at the formatting again, it may be a more proper solution to write something that can understand all of the XML properties required by the service API and allows a user to selectively apply them, possibly allow setting the default tag for the method if no arguments are passed or something similar to keep the simple approach.

Please add unit tests covering the added functionality.

I think the approach to make it a function to apply all the attributes could be good. At present, these are the attributes used in my service code:

• "cl:creator": As the ticket already discusses,
• "nc:operation": replace/merge strategy for config application,
• "xmlns:cl": clixon xmlns - I think this is mostly static,
• "xmlns": Vendor xmlns - this one is tricky and will introduce complications once we have multivendor.